跳转至

Data API 路由至最近的只读副本

文章背景与核心概要

Supabase 近期对其 API 负载均衡器进行了扩展,正式发布了 Data API 的自动地理路由(geo-routing)功能。该技术通过先进的地理空间算法,能够将只读请求智能引导至地理位置上最近的只读副本,从而最大程度地降低全球分布式应用程序的网络延迟。

该更新无需复杂的代码配置,对于使用 API 负载均衡器端点的项目,该功能将自动生效。目前,该初始版本主要支持只读 Data API(PostgREST)请求,未来 Supabase 计划将此功能逐步扩展至 Auth、Storage 和 Realtime 等其他产品线。


什么是地理路由?

地理路由会自动将您的 Data API 请求引导至数据库地理位置最近的只读副本,从而降低延迟,并为全球用户改善响应时间。

Geo-routing automatically directs your Data API requests to the geographically closest read replica of your database, reducing latency and improving response times for your users around the world.

在此之前,如果您在法兰克福、新加坡和弗吉尼亚部署了只读副本,身处欧洲的用户可能会因为处理其请求的副本不同而体验到截然不同的延迟。

Previously, if you had read replicas in Frankfurt, Singapore, and Virginia, a user located in Europe could experience dramatically different latencies depending on which replica happened to handle their request.

我们全新的地理路由功能可自动将用户连接至最近的只读副本,确保例如欧洲用户将专门向法兰克福区域发送请求。

Our new geo-routing automatically connects users to the nearest read replica, ensuring that a European user, for example, will exclusively make requests to the Frankfurt region.

地理路由的工作原理

我们的地理路由系统利用地理空间算法来为每个请求确定最佳的只读副本:

Our geo-routing system uses geospatial algorithms to determine the optimal read replica for each request:

  1. 每个传入的 API 请求都包含来自网络边缘的地理位置数据(具体为 cf.colo 属性,它提供了接收请求的数据中心的 IATA 机场代码)。
    1. Each incoming API request includes geolocation data from the network edge (specifically the cf.colo property, which provides the IATA airport code of the datacenter that received the request).
  2. 我们维护了一个坐标映射系统,将可以部署只读副本的每个区域与精确的地理空间坐标关联起来。
    1. We maintain a coordinate mapping system that associates each region where read replicas can be deployed with precise geospatial coordinates.
  3. 当请求到达时,我们使用哈弗辛公式(Haversine formula)(该公式通过两点的经纬度确定球面上两点之间的最大圆距离)计算网络边缘与每个可用只读副本之间的距离。
    1. When a request arrives, we calculate the distance between the network edge and each available read replica using the Haversine formula (which determines the great-circle distance between two points on a sphere using their longitudes and latitudes).
  4. 系统会自动将请求路由到地理位置最近的只读副本,在不需要您进行任何配置的情况下最大限度地减少网络延迟。
    1. The system automatically routes the request to the geographically closest read replica, minimizing network latency without requiring any configuration on your part.
  5. 在同一区域存在多个数据库的情况下,我们采用轮询(round-robin)策略来确保负载分布均衡。
    1. In cases where multiple databases exist in the same region, we implement a round-robin strategy to ensure balanced load distribution.

整个过程对您的应用程序和用户完全无缝,除了更新您的项目 URL(<project_ref>-all.supabase.co)外,不需要对您的代码或配置做任何更改。

The entire process is completely seamless to your application and users, requiring no changes to your code or configuration besides updating your project URL (<project_ref>-all.supabase.co).

为了充分利用地理路由,请在用户集中的区域部署只读副本。您的只读副本布局越具战略意义,您的用户就越能从低延迟和更快的响应时间中受益。

To get the most from geo-routing, deploy read replicas in regions where your users are concentrated. The more strategically you place your read replicas, the more your users will benefit from reduced latency and improved response times.

初始版本与路线图

作为初始版本,地理路由包含以下注意事项:

As an initial release, geo-routing comes with the following considerations:

  • 目前仅限于只读 Data API (PostgREST) 请求。
    • Currently limited to read-only Data API (PostgREST) requests.

如果您已经在和使用我们的 API 负载均衡器,则无需进行任何操作;地理路由会自动应用于您的 Data API 请求。

If you are already using our API load balancer, there is nothing you need to do; geo-routing is automatically applied to your Data API requests.

否则,您可以通过确保项目使用 API 负载均衡器端点(<project_ref>-all.supabase.co)来启用此功能。

Otherwise, you can enable this feature by ensuring your project is using the API load balancer endpoint (<project_ref>-all.supabase.co).

我们正在积极致力于将地理路由支持扩展到其他 Supabase 产品,例如 Auth、Storage 和 Realtime。请密切关注后续更新。

We're actively working on expanding geo-routing support to other Supabase products, such as Auth, Storage, and Realtime. Stay tuned for updates.

立即开始使用

一如既往,我们欢迎您的反馈——请让我们知道您的想法!

As always, we welcome your feedback—let us know what you think!